The inside story on shared libraries and dynamic loading

are starting to build their applications as extensions to scripting language interpreters or component frameworks. This often involves shared libraries and dynamically load-able modules. However, the inner workings of shared libraries and dynamic loading are some of the least understood and most mysterious areas of software development. In this installment of Scientific Programming, we tour the inner workings of linkers, shared libraries, and dynamically loadable extension modules. Rather than simply providing a tutorial on creating shared libraries on different platforms, we want to provide an overview of how shared libraries work and how to use them to build extensible systems. For illustration, we use a few examples in C/C++ using the gcc compiler on GNU-Linux-i386. However, the concepts generally apply to other programming languages and operating systems. When you build a program, the compiler converts source files to object files. Each object file contains the machine code instructions corresponding to the statements and declarations in the source program. However, closer examination reveals that object files are broken into a collection of sections corresponding to different parts of the source program. For example, the C program #include int x = 42; int main() { printf(" Hello World, x = %d\n " , x); } produces an object file that contains a text section with the machine code instructions of the program, a data section with the global variable x, and a " read-only " section with the string literal Hello World, x = %d\n. Additionally, the object file contains a symbol table for all the identifiers that appear in the source code. An easy way to view the symbol table is with the Unix command nm—for example, $ nm hello.o 00000000 T main U printf 00000000 D x For symbols such as x and main, the symbol table simply contains an offset indicating the symbol's position relative to the beginning of its corresponding section (in this case, main is the first function in the text section, and x is the first variable in the data section). For other symbols such as printf, the symbol is marked as undefined, meaning that it was used but not defined in the source program. To build an executable file, the linker (for example, ld) collects object files and libraries. The linker's primary function is to bind symbolic names to memory addresses. To do this, it first scans the object files and concatenates the object …